Git workflow

Lev Kovalenko

Кратко о git

В кратце рассмотрим струтктуру git - популярную системы контроля версий. Она позволяет совместно работать над проектом множеству разработчиков. В большинстве workflow есть некоторый единый удаленный репозиторий, который хранит в себе все изменения от всех разработчиков. У каждого разработчкика есть локальный репозиторий, синхронизация репозиториев происходит с помощью push и fetch команд. Кроме локально репозитория у разработчика есть индекс (некоторая база отслеживающая файлы и изменения в них) и workspace. При создании нового файла его сначала нужно добавить в index командой git add, а потом создать коммит git commit. Откатиться на изменения в индексе или локальном репозитории можно командами checkout и checkout HEAD. Сравнить состояние workspace можно командами deff и diff HEAD. Команды pull и rebase позволяют подтягивать изменения с удаленного репозитория сразу и в локальный репозиторий, и в workspace. В целом это основной набор команд который вам пригодиться и ими вы чаще всего будете пользоваться при работе с git.

Какие workflow сущесвтуют?

Gitflow

Gitflow одна из первых методологий управления проектом направленное на переодиеские, не частые релизы. В ней есть основная ветка master, в которой хранятся все релизы. До релиза разрабатываемый код находится в ветке develop. Каждое нововведение (фичу) один разработчик разрабатывает в отдельной ветке, после этого она сливается с ветко develop. Когда выолнен весь объем фич для релиза, из develop создается ветка release, в которой ведеться доработка релиза и потом она вливается в master и тегируется, а также вливается в develop. Теги отвечают за версии релизов. В случае обнаружение багов в релизе появляется ветка hotfix в которой исправляются ошибки и она снова вливается в master и develop.

Как видите, методология достаточно тяжеловесная и применима в основном в enterprise разработке, так как она подстраивается под большинство фреймверков управления проектов по водопадной модели. В исследваония применить такую методологию можно, но в результате вы получите очень много overhead для проекта по управлению ветками.

Github flow

Github flow это модификация gitflow предложенная github. Она направлена на снижение количества веток и упрощение поддерживания проекта. В ней оставется две вети - master и feature. Разработка новой функциональности проводится в отдельной фича-ветке, после этого происходит merge в master, после этого происходит новый релиз проекта.

Эта методология построена для проектов управляемых в разлиных гибких методологиях. Одной из важных рекомендаций авторов, является открытие merge request заранее и обсуждение в нем рзличных моментов заранее, до окончания работ. В целом методология достаточно легковесная и гибкая, может подойти для проведения исследвоаний, но в исследваонии нет потребности в такой частоте релизов на начальных этапах.

Forking workflow

Forking workflow это методология поверх github workflow для разработки opensource проектов. Основная сложность в opesource связана с тем, что изначально доступа к изменению в репозитори проекта у потенциального контриьютора нет, поэтому ему предлагается следующая последовательность шагов:

Разработчик «разветвляет» «официальный» серверный репозиторий. Это создает их собственную копию на стороне сервера.
Новая серверная копия клонируется в их локальную систему.
В локальный клон добавлен удаленный путь Git для «официального» репозитория.
Создана новая локальная ветка функции.
Разработчик вносит изменения в новую ветку.
Для изменений создаются новые коммиты.
Ветвь помещается в собственную серверную копию разработчика.
Разработчик открывает запрос на перенос из новой ветки в «официальный» репозиторий.
Запрос на перенос утверждается для слияния и объединяется в исходный серверный репозиторий.

Таким образом организована разработка в opensource преоктах. Могу сказать, что данная методология для исследваоний подходит плохо, из неее можно позаимствовать идею раздельных репозиториев, что если в команде много исследвоателей, то возожно их нужно разнести по разным репозиториям и переодически вытаскивать полезные новвоведения в “официальный” репозиторий.

Datascience lifecycle project

Мы познакомиись с процессами управления гитом распространенными в разработке, теперь перейдем к ds методологиям. Основными отличительными поинтами являются следующие утверждения:

Большая часть кода, который вы пишете, выбрасывается; его ценность заключается в полученных знаниях, а не в самой функциональности.
Часто бывает сложно заранее узнать, как выглядит готовое изделие.
Результат эксперимента сильно зависит от данных и их качества.
Хотя мы не хотим объединять весь наш код в основной, мы не хотим и выбрасывать его.

Основываясь на этих поинтах была разработана методология Datascience lifecycle project. Давайте быстренько пройдемся по нововведениям.

Data branch

Explore and experiment branches

Для исследваония данных предлагется использовать explore branches. Эти ветки отсаются висеть в истории гита без мерджа, потому что код который проводит исследвоание нужен разово что бы подтвердить или опровергнуть гипотезу.

Для экспериментов есть две стратегии, если эксперимент опроверг подход, то такая ветка не получает merge request и просто оставется висеть в истории, так как знания о неудачных экспериментах тоже важны и влияют на принятие следующих решений в развитии проекта.

Для успешного эксперимента ветка переходит в ветку моделей.

Model branches

Хорошая методология?

Плюсы

В основной ветке только важный код.
Сохраняется информация о всех исследваониях.
Имеет “логичные” разделения веток для разных задач.

Минусы

Сложно автоматизировать воспроизвдеение всех исследвланий.
Информация об исследованиях “размазана” по репозиторию.
В теории выглядит хорошо, а на практике…

Методолгия конечно не плохая, но сильно оторвана от реальности. По факту же в проекте большая часть работы связана с обработкой и подготовкой данных, так как чистые датасеты вы встретите только а kaggle, в реальности же придеться очень долго разбираться с данными и возваращаться к ним постоянно. Поэтому хотелось бы как-то просто обновлять результаты уже проведенных исследований.

В целом методология рабочая, но больше подходит для уже существующего проекта, где есть собранные и подготовленные датасеты и основной задачей является моделирование.